home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 3915 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.3 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 2 Feb 1996 10:18:30 +0100
  6. Organization: dis-
  7. Message-ID: <4eskt6$1ea@serpens.rhein.de>
  8. References: <4aj1tc$39r@candelo.dpie.gov.au> <1058.6591T492T1743@cycor.ca> <DLnqBB.DuD@focus-systems.on.ca> <4e442t$4ve@serpens.rhein.de> <DM4Etu.49K@focus-systems.on.ca>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. wayne@focus-systems.on.ca (Wayne Fisher) writes:
  12.  
  13. >I'll admit that I haven't done any large programs under AmigaOS but I
  14. >can't see why the overhead would be an order of magnitude more than
  15. >most other OSs.
  16.  
  17. It isn't. Memory protection under UNIX costs about the same.
  18.  
  19. >The machine I use at work is a fully protected OS running on
  20. >80[345]86s. It supports virtual memory but doesn't page to disk. It's
  21. >realtime and has incredible context switch times. Overhead from memory
  22. >protection cannot be very high.
  23.  
  24. You think about QNX ?
  25.  
  26. >>>although that is a natural extension to it. By virtual memory, I mean
  27. >>>giving all programs a contiguous address space independant of other
  28. >>>programs.
  29. >>This breaks 99% of all programs.
  30.  
  31. >Maybe if you include games
  32.  
  33. No. Games won't run at all unless you boot in a MMU-less state.
  34.  
  35. >but they break on almost any machine that
  36. >is capable of memory protection anyways.
  37.  
  38. I am thinking of regular apps that rely on a flat address space. Just
  39. think about an I/O buffer that is passed to the filesystem and a driver
  40. and maybe even an interrupt system.
  41.  
  42. >And if this was true, I doubt that GigaMem would exist. Nor would it
  43. >work with a number of large commercial applications.
  44.  
  45. GigaMem does _not_ provide separate address spaces for each task.
  46.  
  47. >>>Neither of these features affects the realtime nature of the machine.
  48. >>You bet... It affects speed.
  49.  
  50. >What does speed have to do with realtime. Faster just means you can do
  51. >more in the same amount of time - it isn't a requirement for realtime.
  52.  
  53. While that is true you won't find _any_ realtime application that works
  54. independent of the actual speed. It's not all "task a must complete
  55. before task b". It is also "task a has to run N times per second with
  56. a latency of M milliseconds".
  57.  
  58. >>>    - protect unallocated memory from any accesses.
  59. >>MMU granularity forbids this. You cannot trap accesses to partially
  60. >>allocated pages.
  61.  
  62. >Memory would be allocated to program on a page basis. Sure, you can't
  63. >protect the memory that malloc() hasn't used yet but you can catch
  64. >stray accesses to that 8MB chunk that doesn't belong to anyone.
  65.  
  66. Obviously.
  67.  
  68. >>>    - protect any ROMs from writes.
  69. >>That's code and hardly matters. But protecting all the I/O addresses
  70. >>would help.
  71.  
  72. >Well, it matters if the OS is going to catch it or not.
  73.  
  74. Yes. It is nice to catch bugs. But a write to ROM doesn't do anything
  75. serious that would kill applications. But a single write to an I/O
  76. port can freeze the whole machine.
  77.  
  78. >Remember, OS code can be 'priviledged' and access everyone's data.
  79.  
  80. So, what is OS ? The handler process you simulate in your make utility ?
  81. The BOOPSI gadget that runs on input.device context ? The lowmem-handler
  82. that may execute in supervisor mode ?
  83.  
  84. >The
  85. >biggest thing as far as programs go is in passing messages between
  86. >each other.
  87.  
  88. You understand that most system functions do not pass messages. Instead
  89. you call the system function as a big library. Changing that to pass
  90. messages (even synchronously since you don't want to change semantics)
  91. is going to be abyssmally slow.
  92.  
  93. >And yes, there would have to be some work done on AmigaOS to handle
  94. >access to program data.
  95.  
  96. As I said. It had to be changed completely.
  97.  
  98. >Later OS revisions could expand on this and on what memory is
  99. >protected and how.
  100.  
  101. Sorry, how ? As I said this is something VERY difficult.
  102.  
  103. >Invalid parameters is different from memory protection,
  104.  
  105. No. Memory protection doesn't make sense without parameter checking.
  106. The system cannot simply accept arbitrary pointers for shared objects.
  107. You would have to write code that does not change shared data whenever
  108. the pointer is used to access the object.
  109.  
  110. >What does memory protection have to do with passing a value of 1111 to
  111. >a function that expects something in the range 0-255?
  112.  
  113. The problem that the function can still crash. Without sanity checks
  114. all over your memory protection doesn't do _anything_ to software
  115. stability.
  116.  
  117. >Either force shared data to be explicitly allocated by the program as
  118. >shared to work out a way to let the OS do it. No question, some though
  119. >and work would be required here.
  120.  
  121. You need complete hierarchy schemes. After all you don't want to allow
  122. other tasks to trash your window or gadget structure just because it
  123. was allocated "shared".
  124.  
  125. >I'll admit that I'm not familiar with this area of the OS. However,
  126. >device drivers could become a priviledged part of the OS when they are
  127. >activated.
  128.  
  129. Which already rules out to use any existing driver. Memory protection
  130. on existing machines would be impossible.
  131.  
  132. >>Unfortunately most parameters are passed by pointers. You do have
  133. >>to change everything.
  134.  
  135. >No change as far as the function prototypes of the API are concerned.
  136.  
  137. If you do that you add tons of overhead and still you couldn't catch
  138. everything.
  139.  
  140. Regards,
  141. -- 
  142.                                 Michael van Elst
  143.  
  144. Internet: mlelstv@serpens.rhein.de
  145.                                 "A potential Snark may lurk in every tree."
  146.